The present invention relates to computer generated imagery, e.g. computer animation. More specifically, the present invention relates to methods and apparatus for providing texture maps to surfaces with increased efficiency and increased quality.
The inventors of the present invention have previously utilized a computer animation pipeline for modeling elements for computer animation. Many of these elements have been modeled using Catmull-Clark subdivision surfaces and shaded using general-purpose shaders with multiple layers (e.g. a dozen or more) of attributes such as color and displacement. These attributes are typically controlled by texture maps that have been created using a combination of procedural generation methods and hand-painting methods.
The inventors of the present invention recognize that using texture maps based upon procedurally-generated textures generally provide faster and more predictable rendering times. Further, procedurally-generated textures often produce lower filtering and anti-aliasing artifacts. However, purely procedural shaders are often computationally expensive, difficult to art direct, and are often difficult to anti-alias. Accordingly, the inventors have determined that various embodiments of computer animation pipelines should be parameterized for painting.
The inventors recognize that many parameterization methods for an animation pipeline have been contemplated, but few of them have considered the impact of pre-processing on a production pipeline. For example, a pipeline with manual intervention (e.g., manual adjusting of seam placement) is time consuming for the user. As another example, a fully automatic pipeline is also time consuming, as parameterizing a mesh introduces an extra dependency in an animation pipeline in-between modeling and painting/rendering.
The inventors have previously implemented texture mapping pipelines based upon decomposing subdivision surfaces into rectangular groups of faces which are termed “patches.” Using conventional techniques, texture maps 100 are mapped from texture map coordinates of (s, t) to each of the patches, using surface coordinates (u, v). An example of this mapping is illustrated in FIG. 1A. Such embodiments have been considered robust but resource intensive. For example, because each patch has required a separate texture file 100, often a large number of separate texture files are required for each surface. In light of this, within a scene, the I/O (input/output) cost of accessing, for example 1,000,000 separate texture files, is considered by the inventors as very time consuming. Additionally, other per-patch runtime costs in tools for processing the patches (layout and animation tools, painting tools, RIB generators, etc.) also reduce performance. An additional drawback includes that patches must be generated for a mesh before it can be painted or rendered with full shading.
Other drawbacks determined by the inventors include that such pipelines often produce visual artifacts due to clamping at patch boundaries. Such artifacts are often visible when smooth displacement maps are applied to a surface with a strong specular or reflective response. An example of this is illustrated in FIG. 1B where a surface is rendered with five patches. In FIG. 1B, patch seams 110 are illustrated by the star-like pattern emanating from the center of the surface. Some work-arounds for such artifacts have included: limiting how users can define smooth features of an object, by modeling smooth features into the base surface rather than using displacement maps; by adding noise to displacement maps (if appropriate to the look); and/or by using normal maps in addition to, or instead of displacement maps. Such limitations undesirably restrict the creativity and flexibility of the artists who are charged with producing the computer generated imagery.
The inventors have considered a number of alternative ways to address the issues described above. However, many alternatives do not consider the high quality filtering needs of production rendering, and many do not improve efficiency, and/or reduce pipeline efficiency.
Once set of techniques utilize planar domains. In such techniques, parameterization methods flatten the entire mesh onto a plane and use the planar coordinates as texture coordinates. However, unless the mesh has genus 0 (is disk-like), unfolding the mesh requires one or more cuts. This results in visible seam artifacts when filtering across cuts, which map to discontinuous boundaries in texture space. One technique places cuts in areas of high curvature and occlusion. Another technique places cuts in areas of high curvature and stores sideband data, which allows stitching of the boundary for seamless rendering. Such techniques, however do not provide a solution for prefiltering of mipmaps, or the like.
Distortion is also an issue with the methods above. To reduce distortion, the mesh can be decomposed into multiple patches which are separately flattened onto charts and packed into a texture atlas. A drawback to this is that packing wastes texture space, and seams still are apparent when adjacent patches map to non-adjacent charts. In some methods, to hide seams, a small gutter around rectangular charts are provided at each mipmap level. Additionally, the texture coordinates are adjusted so that a trilinear filter never spans a gutter. All of these additional techniques, however, undesirably increase the processing time.
Another set of techniques utilize spherical and/or other domains. In such techniques, instead of mapping a mesh to a plane, the mesh is mapped to a sphere, or the like. Seamless, low-distortion mapping to a sphere were proposed for genus 1 meshes, and a generalization of spherical mapping was proposed for arbitrary meshes. Such techniques sometimes distribute texture area very non-uniformly. In the case of PolyCube maps, textures are stored on multiple cubes which roughly approximate the mesh. However, PolyCube maps have been asserted to be not practical for very complex meshes, as is common found with state-of the art computer generated imagery.
Another set of techniques rely upon projection mapping, and does not require assigned UVs. In such techniques, texture values are looked up with a projection onto a plane or other parametric surface. A depth map is then used to prevent texture values from projecting through geometry. The inventors believe that such techniques may work well for more simple objects and would not obviate the need for a patch creation step in a rendering pipeline. However, there may be an increase in cost in painting and rendering of an element.
Additional possible drawbacks includes that multiple projections may be required to cover complex geometry, and that blending between projections may require some amount of overpainting and undesirable manual intervention to remove artifacts. Other possible drawbacks include that additional texture space and additional texture lookups may be required. This is because additionally multiple perspective matrix transforms, depth map and color map lookups may be necessary per shading point.
Yet another set of techniques rely upon volumetric textures. In such examples, texture values can be stored in a volumetric data structure such as a 3d grid, an octree, or a Brick map. Grids, however, require a large amount of storage; and adaptive, tree-based structures, such brick maps also require much more storage than 2D textures. Other drawbacks include a logarithmic time for lookups; filtering issues with volumetric data, since filtering is linear and takes place in three-dimensions rather than on a surface; and colors can bleed through nearby surfaces (e.g., clothes and skin), so those surfaces have to be stored in separate maps.
In light of the above, techniques for providing texture maps to surfaces with increased efficiency and increased quality are desired.